1. Field of the Invention
The present invention relates to a hierarchical database management system, a hierarchical database management method and a hierarchical database management program which manage a hierarchical database.
2. Description of the Related Art
In versatile operating systems (OSs) such as an Microsoft Windows (™), UNIX (™) or LINUX (™), a tree view has been adopted as a graphical user interface (GUI). A tree-like directory structure or file structure is visually presented to the user by the tree view so that the user can navigate to a specific directory or file.
In respective nodes in the tree view, however, there in no relationship such as an inheritance relationship or an inclusive or subset relationship between information included in a high-order node and information included in a low-order node. Nodes prefixed by a root node in the tree just indicate that holders for information such as files, i.e., containers, are connected with each other in a tree form. This kind of structure is referred to as “hierarchical directory structure” in the description of this specification, and it is differentiated from a hierarchical database in this specification. In the present invention, a unit of information that characterizes a class and is associated with the class is referred to as a “property”, and each information field or element that constitutes the information structure of the class or property is referred to as an “attribute”.
On the other hand, a database as typified by an object-oriented database (OODB) or an object-relational database (ORDB) has a hierarchical structure in which a sub-class inherits to a property of a super class. In this database, the property increases progressively in the sub-class in accordance with inheritance. Here, the “inheritance” means the transmission of the properties of super class into its sub-class(es). Such a technique is described in, e.g., “Object-oriented Concepts, Database, and Applications”, edited by Won Kim, 1989, ACM Press and many other references. Further, in the object-oriented database, a classification in a hierarchy is often called “class”. On the other hand, in the object-relational database (ORDB), a table which has allowed inheritance corresponds to the inheritance, and a lower-order table inherits to a property from a high-order table between tables having hyponymy. That is, a lower-order table inherits header information of a column constituting a high-order table. In this specification, OODB and ORDB collectively mean “hierarchical database”. Data having the same property type belonging to the classification of respective hierarchies is referred to as an “instance”, and a set of such data is referred to as “population”. A population of data is stored in a structure which is usually referred to as a table in a relational database (RDB) or ORDB. In a table, a line of properties constituting the table is called a header of the table.
A hierarchical database having a hierarchical structure as typified by an object-oriented database in which a sub-class inherits a property of a super class has a structure in which the property increases progressively in the sub-class in accordance with inheritance. Therefore, in case of setting an import of a specific property from a class in one dictionary 1 to a class in an other dictionary 2 or a multiple inheritance of all properties, a sub-class in a classification system of dictionary 2 inherits an imported class property of dictionary 1. In this case, generally, a sub-class which is equal to or inferior to the above-described class in the classification system in dictionary 2 is affected by revision of a definition of the corresponding property in dictionary 1. Furthermore, when complying with ISO 13584 Parts Library standards Part 24 (standards—volume No. 24), in character string type properties having language dependent values, identity between properties whose values can be written in multiple languages is essentially determined by codes which do not have linguistic meanings. Therefore, when, e.g., classes are implemented as tables in a database in accordance with the ISO 13584 standards, whether two classes are the same type must be judged by using codes in headers of the tables (alignments of properties) which are not dependent on the usual linguistic semantic interpretation (rather than codes in which character strings have regular linguistic meanings as typified by, e.g., “Product name”).
When classes having the same concept exist in two standard classification dictionaries, it is normal in a conventional example that one dictionary issues codes irrespective of the other dictionary, and a GUI symbol as a class reference to another class in another dictionary is provided in a database storing both dictionaries so that reference from one dictionary class to the other dictionary class is indicated. As many GUI symbols, the same icons as folders or directories are used. Problems of this example are as follows.
(i) First, when these dictionaries are treated as a simple link which does not have a property inheritance relationship at all, the revision of the property definition can be independently carried out between one dictionary and another. If this revision of the definition is allowed, types and definition contents of properties of classes in both dictionaries become far different with time. As described above, it is hard to stably share the same concept between two classes in the two standard classification dictionaries. Moreover, when class names are given in multiple languages in one dictionary, reference to another class in another dictionary which also uses the same or different set of languages cannot be realized with a simple link mechanism which directly links a class name in one language to another class name in another language, unless a special function to search for a translated name related to the linked class corresponding to the language of the referencing class, or a translation mechanism from the language of the linked class to the language of the referencing class is provided.
On the other hand, when this reference relationship is treated as an inheritance relationship, there is the following problem.
(ii) A class in one dictionary inherits properties of a class in the other dictionary. As a result, the similarity of the classes in both dictionaries is maintained, but one dictionary is affected by the revision of the property definition of the other dictionary. For example, when a property is added to a class in one dictionary, a structure of the database must be changed and the property must be added in a class of the other dictionary making reference to the former class. Of course, in this case, both classes, property identification codes and others must be matched with each other.
In a conventional hierarchical database management technique, when two standard classification dictionaries have classes having the same concept, it is normal to provide a GUI symbol as a class reference to anther class in another dictionary so that reference from one dictionary class to the other dictionary class is expressed.
However, in case of treating reference to classes as a simple link which does not have a property inheritance relationship at all, types or definition contents of properties of both classes become far different with time, and it is hard to stably share the same concept between the two classes in two classification dictionaries.
Additionally, when a reference relationship between two classes in two dictionaries is treated as an inheritance relationship, since a class in one dictionary inherits a property of a class in the other dictionary, the similarity of the classes in both dictionaries can be maintained. However, one dictionary is affected by the revision of the property definition of the other dictionary. In this case, dictionary revision work becomes complicated.